1. Technical Field
The present disclosure generally relates to the field of computerized systems and methods. More particularly, the disclosure relates to computerized systems and methods that provide a dynamic service-oriented architecture using customization code.
2. Background Information
In software engineering, a service-oriented architecture (SOA) provides resources for performing particular functions as independent services that are accessible in a standardized way over a network. The services are considered standardized because distributed program components can invoke the services without any knowledge of an underlying platform that supports the services. The services can communicate and coordinate with one another to perform various activities for a variety of entities that are considered to be tenants of the SOA. For example, an entity that is operating as a retailer might use services that perform activities such as order processing, payment processing, and order fulfillment.
SOAs provides flexibility because heterogeneous components can be assembled into a functioning distributed system. However, due to the heterogeneity of the components and the lack of common extensibility mechanisms, SOAs tend to be single-purpose platforms that serve a single business entity. This kind of single-purpose architecture is contrary to the goals of a typical platform vendor, which might want to provide services to a large number of various entities that each have different business needs and goals. For example, a typical order fulfillment service, for example, may include various services, such as “Create Order,” “Fulfill Order,” “Ship Order,” “Invoice Order,” “Cancel/Update Order.” Certain entities may wish to customize some aspect of one or more of these services due to a need to, for example, implement specific order processing rules, tax calculation rules, or other workflow steps.
Since a platform vendor may provide services to potentially hundreds of entities, it may be necessary to create customized services on a per entity per service basis. Consequently, the platform vendor may create a large number of services that essentially implement the same functionality, but variously include some customized feature. Moreover, since a service is a running instance of an object, a new service may need to be instantiated for each entity that requires a customized service. Instantiating a new service typically requires a new process, virtual machine, or host to execute the service. Increasing the number of objects in an SOA-based environment each time an entity requires a customized service creates operational complexity because more and more heterogeneity is introduced into the system and more system resources are consumed.
Typically, the primary mechanism for extending an SOA is to build new applications on top of underlying functionality. However, including customization and additional business logic at the application layer may cause performance, security, and manageability issues in an SOA environment where many entities make use of the services that are provided by the SOA. As result, a service owner may try to implement all of functionality that is required by the entities that use a particular service. However, this results in application-specific functionality being incorporated into the services themselves and increases the number of objects in the SOA environment that are required to deliver the functionality.
As is evident from the above, it is instead desirable to provide an extensible architecture in which services may be customized without altering existing program code or creating additional objects of the same service. However, customizing services for a particular entity without causing an increase in the number of objects is not feasible under a typical SOA. Accordingly, there is a need for improved systems and methods that provide an extensible SOA without causing the drawbacks discussed above.